RFP Guide

How to Develop and Manage RFPs for ICT

 

 

 

 

 

An RFP (Request for Proposals), also known as a bid, is a very effective tool for contracting and outsourcing services in the public as well as private sectors around the globe. This document, generated by the Computer Aided Strategic Planner after an interview, is intended to help government officials develop an RFP for ICT services (i.e., eservices). It consists of the following sections:

Section 1: Background Information about RFPs with some general guidelines for developing and managing RFPs

Section 2: Sample RFP Templates with links to sample RFPs and also a link to the Strategic Planner Sample RFP for downloading

Section 3: Problem Specific RFP that shows the main results generated by Strategic Planner. These results are very problem and project specific and form the Technical Content (or Terms of Reference) in the RFP. This is the most important part and differentiates one RFP from another. :

How to Use This Document

The following diagram illustrates the overall process used by Strategic Planner to produce the RFP Guide and also the Customized RFP:

 

 

Guidelines for Developing an RFP  

Developing a solid RFP is tedious and time consuming process with many options that need to be explored and investigated. Common issues that arise during an RFP preparation are:

  • How many services should be included in one bid (is it better to bid sepearately for each service)
  • How to decide what should be bought (packages already available), rented, outsourced, developed in house, or extended/reused (i.e., use the licenses or software already present).
  • How much detail should be specified for the hardware  

 

It is best to use a systematic BRODE(Buy, Rent, Outsource, Develop, Extend) methodology  consisting of the following steps instead of chasing every possible option: 

S1: Develop a logical diagram of the solution architecture under consideration. The following diagram shows a general logical architecture that could be used for the purpose of illustration:

The integration service just shows how the participating services are connected. In many cases, we need to see and understand how the information flows from the user  service bus through the agencies to the B2B integration bus.    

The composite solutions in the Planner show below the dotted line solution and the individual services show above the dotted line.

 

S2: Divide the diagram in terms of logical blocks (L1, L2, L3,,, etc).  The following logical blocks can be developed from the above diagram. Each of these logical blocks (modules) can be outsourced or developed in house

 

A: ESB Preparation

A1: ESB acquisition, and installation

A2: ESB configuration and customization

A3: Development of adapters

A4:  Population of Directory and Data Dictionary

A5: Specification of rules and policies

A6: Enabling the workflow

A7: Establishing the security

A8: Testing the ESB environment

 

B: Development of Software for Each Organization Unit 

B1: Developing the ESB clients

B2: Connecting the local apps with the clients

B3: Testing  the software and ESB clients at each site

 

C: Project Management

C1: Preparing a project plan

C2: Monitoring and controlling the plan

C3: Preparing a Business Continuity Plan

C4: Risk analysis

 

S3: For each block, lets say B1,  decide on BRODE, based on factors such as TCO (total cost of ownership, time to implement, flexibility, internal skillset, business strategy, etc. For example, an ERP package means that you are buying a bunch of blocks. .

S4: Repeat S3 for all building blocks that are left over. For example, if a commercial package covers 5 out of the 8 blocks, then now you decide what is your BRODE strategy for the remaining 3 blocks. 

S5: After you are done, you will have a few components that are bought, a few that are rented, some are extended/reused from extended systems, etc. Now you can estimate the critical factors (e.g., TCO)  for the solution. If you are happy with this solution, you are done. If not, then go back and to S3 and reiterate S3, S4 and S5 till you are done. In practice, you should not go through the iteration more than a few times (probably three to five).         

Once you found a solution that makes sense and you want to procure it, then you can proceed with developing the RFP based on the solution.

Once you have found a solution that makes sense and you want to go with it, then you can proceed with developing the RFP based on the solution. Here are some additional suggestions about developing an RFP:

  • Let the potential contractor (bidder) do as much work as possible 
  • Include hardware specifications only if the proposed system is supposed to run on the existing hardware and operating system
  • Hardware sizing primarily is determined by the number of users. You should select the hardware that can be easily scaled
  • Consider renting as an option in the pilot phase of a project. It is much cheaper than buying and can be purchased if it works well
  • In most cases, cost (total cost of ownership) is the main criteria for selection.  However, the contractor must provide a system that works  and is scalable.   

 

 

 

 

 

 

An RFP is a commonly used document for soliciting submittal of proposals in response to a scope of work. RFPs are used as a basic tool for contracting goods or services.

An RFP must be a clear, concise and consistent document that provides enough information to the prospective vendors but avoid unnecessary details. It must provide the following pieces of information:

Many guidelines for developing RFPs are available on the Internet. Here are a couple of examples:

 

 

 

Strategic Planner RFP Template

Many companies sell RFP templates for different types of packages for a fee. See, for example, http://rfp.technologyevaluation.com/store.asp

View Strategic Planner RFP Service Specifications

RFP_TemplateDownload Strategic Planner RFP Service Specifications

.

 

 

NOTE: The following specification shows the main results generated by Strategic Planner. These results are very problem and project specific and form the Technical Content (or Terms of Reference) in the RFP. Carefully read the following report to develop an understanding of all the information that can be used to develop and manage an RFP.

This information is not in a format to be sent out for bidding. It covers many aspects of the service being provided.

Depending on the type of outsourcing (everything versus only one part), some of the information will be important to the RFP providers and the other to the RFP responders.

You need to build a customized RFP from the following information for your situation by extracting the needed portions and customizing the technical content from the information.

For help in creating a customized RFP, please invoke the Strategic Planner RFP Generator it will create a draft customized RFP to get you started. . .